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WEB BASED SERVICE REQUEST AND APPROVAL SYSTEM 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] Not applicable. 

STATEMENT REGARDING FEDERALLY SPONSORED 
RESEARCH OR DEVELOPMENT 

[0002] Not applicable. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

[0003] The preferred embodiments of the present invention are directed to a web based service 
request and automated approval system. More particularly, the preferred embodiments are directed 
to a web based service request system in which services are selected from predefined categories by 
the requestor, and approvals by persons responsible are obtained electronically. 

Background of the Invention 

[0004] It has become common in the world of business to have Information Technology (IT) 
incident reports and work requests in an automated system for tracking purposes, known as help- 
desk software. One such help-desk software product is the Clarify eFront Office software 
produced by Amdocs Ltd. 

[0005] In related art Clarify operations, customers (whether internal to the corporation or 
external), call a telephone number and are connected to a help-desk operator. The customer 
explains the service problem and the help-desk operator keys in the problem or request in free- 
form mode. Examples of possible problems or requests could be service related to computers, for 
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example hardware failures, or the possible problems could be associated with operation of a 
particular software program. The customer may also place a service request, for example the 
creation of an electronic mail account, a user account on the company's network, and the like. 
[0006] Generally in the related art, the individual keying in the customer's complaint or service 
request creates what is known as a "case" in the Clarify system. If the case is a trouble report 
related to hardware or software, it is unlikely that any form of approval is required before a service 
technician addresses the problem. If, however, the case is a request for creation of new services, 
for example creation of an SAP account in multiple modules, relocation of computer hardware, 
creation of a new electronic mail account, and the like, it is likely that some form of approval will 
be required. 

[0007] In related art systems, after creation of the case in the help-desk software, approvals are 
generally acquired by an individual contacting each required approver in the approval chain. This 
is a manual process, and depending on the number of approvers in the approval chain, may take 
many hours or even days. If the requested service is not approved, an individual (whether the help- 
desk operator or the service technician) must close the case in the Clarify system. 
[0008] As can be appreciated from the above description, the process, while being automated to 
some extent, still requires significant human intervention. This is especially true when entering the 
information to create a case in the help-desk software system such as the Clarify system, and is 
also true in the approval process. What is needed in the art is a way to streamline the case entry 
and approval process. 
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BRIEF SUMMARY OF SOME OF THE PREFERRED EMBODIMENTS 
[0009] The problems noted above are solved in large part by a method and related system of 
automating the entry and approval process for cases in Clarify or Clarify-type help-desk software 
systems. In the preferred embodiments, customers (whether internal or external) input then- 
request by way of a web-based system. This alleviates an aspect of the need for a help-desk 
operator. Further, rather than inputting the information in a free-form style, the customer is 
allowed to select from previously defmed services and service categories in a fashion similar to an 
on-line shopping cart system. Once the customer has finished making the desired selections, the 
customer submits the request. 

[0010] After submission, the one or more requests are analyzed for their particular requirements, 
which are also preferably predefined. To the extent a request does not require financial or 
technical approval, the request is submitted to the help-desk software, preferably the Clarify 
software system, for creation of a case. If, however, the customer's request requires approval, 
preferably the person or persons responsible for approving that request are sent an electronic mail 
notification containing a clickable link to a web-based approval site. Once all the necessary 
approvals are obtained, preferably the system creates a case in the Clarify system. In the event that 
one or more approvals are denied, preferably the system electronic mails the customer that his/her 
request has been denied. 

[0011] In this way, the entry process is automated in a familiar online shopping cart format, 
eliminating the need for a person to transcribe information into the Clarify system. Moreover, a 
case is not created in the Clarify system until all the necessary approvals, if any, are obtained. 
Relatedly, the approval system is automated, thus eliminating the need for a help-desk operator or 
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technician servicing the cases to be responsible for verifying approval for the request before 
performing the desired tasks. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0012] For a detailed description of the preferred embodiments of the invention, reference will 
now be made to the accompanying drawings in which: 

[0013] Figure 1 shows, in block diagram form, the various components of the preferred 
embodiments; 

[0014] Figure 2 shows an exemplary web-based screen showing selection of services from 
predefined categories; 

5 [0015] Figure 3 shows an exemplary web-based screen showing service catalog summary 

111 

VI information for an exemplary predefined service; and 

5 [0016] Figure 4 shows a flow diagram of the preferred service selection, approval and case 
creation method. 

fi NOTATION AND NOMENCLATURE 

W 

p [0017] Certain terms are used throughout the following description and claims to refer to 
particular system components. As one skilled in the art will appreciate, computer companies may 
refer to a component by different names. This document does not intend to distinguish between 
components that differ in name but not function. 

[0018] In the following discussion and in the claims, the terms "including" and "comprising" are 
used in an open-ended fashion, and thus should be interpreted to mean "including, but not limited 
to...". 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
[0019] The preferred embodiments of the present invention are directed to automating the 
process of entering cases in a help-desk software system. The preferred embodiments may be 
logically, though not necessarily physically, divided into four major components. Figure 1 shows 
these four logical components of the preferred embodiment (user interface 10, approval 
component 12, help-desk software interface 1 8 and help-desk software 20), and how generally they 
interact. 

[0020] In particular, customers or requestors access the system by way of a user interface 
component 10. It is within the user interface component 10 that the customer or requestor enters a 
specific request, which is discussed more thoroughly below. The results of the customer entering 
the request in the user interface 10 are transferred to an approval component 12. The approval 
component 12 is preferably responsible for notifying approvers and gathering approval or denial 
information. If the request is denied, the approval logic 12 generates an electronic mail (e-mail) 
message to the customer or requestor 8 indicating the denial of the request, as indicated by line 14 
of Figure 1 . It is possible, however, that a particular service request does not require approval, and 
thus the approval component 12 may be skipped in its entirety as indicated by dashed line 16 of 
Figure 1. The next logical component is the help-desk interface component 18 which gathers its 
information from the approval component 12. The interface logic 18 preferably handles 
communicating to and from the help-desk software 20. The help-desk software 20 may be any 
available help-desk type software for managing information technology or related issues. In the 
preferred embodiment, the help-desk software 20 is the Clarify software program offered by 
Amdocs Ltd. One of ordinary skill in the art is familiar with the use of Clarify and Clarify-type 
help-desk software programs. 
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[0021] The user interface component 10 is preferably accessed by the customer or requestor by 
way of a web-based interface. In this way, the requestor or customer need only have access to the 
internet and standard web browser to enter service requests. Preferably, the user interface 
component 10 operates on principles similar to on-line shopping software, also known as Shopping 
Cart software. In particular, preferably service requests are entered by interactively selecting and 
holding service request items from pre-defined lists for prospective submission. Figure 2 shows an 
exemplary user interface screen from which a customer may select service catalog items. Figure 2 
exemplifies the preferred catalog format service requesting by showing four service requests 
identified in a catalog description search using the search string ee New%" where the "%" is a wild- 
card identifier. In this exemplary system, four service catalog items were identified, namely: new 
electronic mail account, new NT account, new NT account - Massachusetts, and new SAP 
account. Although only four such service catalog items are shown in Figure 2, it must be 
understood that many service catalog items may be available to the customer in the preferred 
embodiments. These service catalog items may also comprise requesting repair of particular 
hardware (also providing a field for a brief description of the problem), requests for relocation of 
hardware devices such as computers and printers (also providing a field for a description of the 
new and old locations), and the like. Figure 2 also exemplifies that a requestor or customer may, in 
the preferred embodiments, select multiple services from the service catalog items in any one 
session. 

[0022] Preferably, each service catalog item has a set-up screen which defines important 
characteristic of the service in the overall system. Figure 3 exemplifies a service catalog summary 
screen that shows the pertinent information associated with a service catalog being a New 
Electronic Mail Account - Massachusetts. The New Email Account - Massachusetts is allowed 
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to be published on the web and is assigned a help-desk queue "CAM." As one of ordinary skill in 
the art is aware, queues in the help-desk software are where cases are placed for servicing, 
typically in a first-in first-out manner. This exemplary catalog summary screen on a New Email 
Account ~ Massachusetts also indicates that approval is required for this particular service catalog 
item. Finally, though preferably the services are selected from service catalog items, it may be 
necessary in some cases to provide additional information so that the service may be fulfilled. In 
the exemplary case shown in Figure 3, the additional information needed is the size of the mailbox 
requested. In other cases, for example, relocation of a computer from one location to another, it 
may be necessary to input additional information in the form of the name of the computer and 
current location, as well as the destination location of the computer. One of ordinary skill in the 
art, now understanding the concept of selecting computer related services through a service catalog 
item list could easily create many service catalog items, including fields for entry of service- 
specific information, without departing from the scope and spirit of this invention. 
[0023] After selecting the service or services desired from the catalog, and entering any 
necessary information associated with any of the service catalog items, preferably the customer or 
requestor proceeds to a submission or check-out stage, where the customer may have the 
opportunity to review again the services requested, and remove any of those services that the 
customer deems are no longer necessary. Once final changes are made, if any, the customer 
"checks out" or submits the request. 

[0024] As alluded to above, some requests may need approval prior to performing the services 
desired. Referring again to Figure 1, the user interface component 10 preferably submits the 
request generated to the approval component 12. In broad terms, the approval component 12 is 
responsible for electronically gathering approvals for service catalog item requests. More 
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particularly, the approval component 12 preferably analyzes the service request passed by the user 
interface component 10. If the service requests entered do not require approval, effectively the 
approval component 12 is by-passed, as symbolically indicated by dashed line 16. If, however, 
one or more of the services selected requires approval, the approval component 12 preferably 
generates an e-mail message to that approver, and includes in the text of that electronic mail 
message a URL link to a web site. Preferably, the approver receives the e-mail, clicks the 
hyperlink to the URL provided and approves or denies the request. 

[0025] It should be understood that the approval process may take different forms for different 
service requests, and indeed may vary between different companies. For example, for some 
service requests, only technical approval may be required. For other service requests, for example 
the relocation of a computer system, both a financial approval and a technical approval may be 
required. Further still, in some organizations, the approval chain may be hierarchical, and thus the 
approval component 12 may be responsible for sending a plurality of electronic mails to different 
approvers, one at a time, sending the next e-mail if the previous approver approves the service 
request in question, 

[0026] Figure 4 shows a flow diagram of the service entry process of the preferred embodiment. 
In particular, the process starts at step 30 and progresses to a customer selecting services from the 
catalog entries (step 32). Selecting services from the catalog entries preferably takes place in the 
user interface component 10, as shown in Figure 1. 

[0027] After selection of the desired service catalog items, a decision is made regarding whether 
the services selected require approval (step 34). If no approval is required for the service or 
services selected by the requestor, then the procedure proceeds along line 36 to step 42, which is 
discussed more thoroughly below. If, however, approval for a service request is required, 
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preferably the next step is the generation of electronic mail messages which are sent to the 
predetermined approvers (step 38). Preferably, the electronic messages contain a link to a URL 
which takes the approver to a web based location where he or she can approve or deny the request. 
After generation of the electronic mail messages to the approvers in step 38, the next step is the 
determination as to whether the particular service request or requests have been approved (step 40). 
In the preferred embodiments, each service request is handled independently. Thus, if a requestor 
selects two services, one of which requires approval and a second that does not, then preferably the 
procedure exemplified in Figure 4 bypasses the approval process for that service or services that do 
not require approval (line 36). The service or services that do require approval, however, enter the 
approval process (steps 38 and 40). Thus, in the preferred embodiments, though services may be 
selected substantially simultaneously, each service selected becomes an independent case, an 
independent tracking entry, in the preferred Clarify help-desk software. 

[00281 If the particular service request is approved as determined at step 40, the process proceeds 
to step 42, where a case for the service is created in the help-desk system. If, however, the 
approval is denied, the process proceeds to step 44 where an electronic message is generated to the 
customer indicating that the requested service has been denied. Before proceeding, it must be 
understood that the preferred embodiments of the present invention are not limited to any particular 
type of approval process. As discussed above, there may only be a single level of approval, for 
example, a technical approval. Likewise, there may be both financial and technical approval, 
which may be the same or different people. Moreover, the approval process may be hierarchical at 
both the financial and technical levels such that the generation of electronic mail approvals in 
step 38 and evaluation as to approval of disapproval in step 48 may be serially repeated for each 
person in the approval chain. 
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[0029] If the service selected does not require approval, or if approval has already been obtained 
through the use of steps 38 and 40, the next step in the preferred embodiment is the creation of the 
case in the help-desk system. In the preferred embodiments, the help-desk system is a Clarify 
help-desk program produced by Amdocs Ltd. If case creation is successful in the help-desk system 
(step 46), then the case creation status is preferably propagated back to the user interface 
component 10 (step 48). In this way, the requestor or customer need merely check the status to 
obtain a case number in the help-desk system, for example for tracking purposes. If however, 
creation of the case was unsuccessful in the help-desk software, preferably an electronic message is 
generated to the customer or requestor indicating the failure of their request. 
[0030] Referring somewhat simultaneously to Figures 1 and 4, those steps performed by the user 
interface component 10 of the preferred embodiment are the selection of the service from the 
catalog entries step above dashed line 50 of Figure 4. The approval component 12 preferably 
implements the steps between dashed lines 50 and 52 of Figure 4, in particular steps 34, 38, 40 and 
44. Line 14 of Figure 1 is exemplary of generating the electronic message to the customer upon a 
denial of the service request at step 44. The steps of Figure 4 below line 52 are preferably 
implemented in a combination of the interface component 18 and the help-desk software 20. In 
particular, propagating the status of the case creation to the user interface component (step 48) is 
exemplified by line 62 of Figure 1. Likewise, line 64 is exemplary of the help-desk software 20 
generating an electronic message to the customer upon a failure of creation of the case in the help- 
desk system (step 50). 

[0031] In the preferred embodiments, the user interface module is preferably a software program 
written in one or both of the ASP or HTML programming language. Generating electronic mail to 
approvers seeking their approval or denial of a service request, as well as evaluating those 
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responses, in the preferred embodiments is developed using Microsoft Technology, particularly - 
Microsoft Visual Interdev Studio development environment. Finally, the interface component 18 
is preferably written in Microsoft Visual Studio. However, while these are the preferred languages 
for implementing the various tasks described, one of ordinary skill in the art, now understanding 
the procedures and requirements of the system, could easily design equivalent systems in these or 
different programming languages. 

[0032] The above discussion is meant to be illustrative of the principles and various 
embodiments of the present invention. Numerous variations and modifications will become 
apparent to those skilled in the art once the above disclosure is fully appreciated. For example, it is 
envisioned that all the software components used to implement the preferred embodiments will be 
stored and executed on a single computer system; however, each individual component may reside 
on an individual computer or server system linked by communication networks, and such a system 
would still be within the contemplation of this invention. Further, there may be many help-desk 
type software systems available on the market, and each of those help-desk type systems could be 
equivalently used in the embodiments described. While each of the various components of the 
preferred embodiment are described as individual software components, it is possible that the 
functionality embodied in all the various components may be written into or contained in a single 
software program, and this too would be within the contemplation of this invention. It is intended 
that the following claims be interpreted to embrace all such variations and modifications. 
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